\subsubsection*{Risk 1: Module Conflicts}
During the design phase, modules are created based on data abstractions. Every
component in the system is assumed to work flawlessly with the other components
in the system. Some inter-module conflicts may actually occur during the actual
implementation and coding.
\\
\\{\bf Likelihood of occurring:} low
\\{\bf Impact if it occurs:} low
\\{\bf Evidence:}
An experimental version similar to zero-feature release has been made to address this issue.
If problems occur, the impact should be low because the main purpose of modularization is
to address this problem.
\\{\bf Steps to reduce likelihood/impact:}

1. Better communication between people that are assigned to interacting modules

2. When any changes are made to a module, test that module against all its dependencies.
\\{\bf Plan for detecting the problem:}
The problem will be detected through processes discussed under Test Plans
\\{\bf Mitigation plan should it occur:}
Resolve the conflict immediately. If the conflict affects the overall design of the system,
research and discuss alternative implementations that were considered during the architecture
design phase.

\subsubsection*{Risk 2: UI Changes}
\\
After showing the zero-feature release with a basic UI template to our customer,
zero to many changes may be required depending on how much the customer likes
the UI design.
\\
\\{\bf Likelihood of occurring:} medium
\\{\bf Impact if it occurs:} low-medium
\\{\bf Evidence:} The paper-prototype helped us determine how well the customers
liked our UI design, but the paper-prototype does not reflect any real visual
qualities. The likelihood of this issue occurring is greatest earlier in the
process of completion. It will be less likely for the customer to dislike the UI
design after many changes.
\\{\bf Steps to reduce likelihood/impact:}

  1. Have every team member review and give feedback on how the UI looks.

  2. Look at similar systems for similar UI designs
\\{\bf Plan for detecting the problem:}
Have regular customer meetings and show them how the UI looks
\\{\bf Mitigation plan should it occur:}
Discuss with customer on the parts that are liked/disliked and ask if any existing UI designs
are preferred

\subsubsection*{Risk 3: Frustrated Programmers}
\\
Work is divided among the team base on different modules in the system. The workloads are
not necessarily the same for everyone.
\\
\\{\bf Likelihood of occurring:} medium
\\{\bf Impact if it occurs:} medium
\\{\bf Evidence:}
Our team consists of only six people. Unless one of us manages to finish a lot faster than
the rest of us, it will be hard to allocate extra human resource should this problem occur.
\\{\bf Steps to reduce likelihood/impact:}

1. Routine status updates and review progress during meetings
\\{\bf Plan for detecting the problem:}
The project manager/ the struggling member should raise this issue to the team should it occur.
\\{\bf Mitigation plan should it occur:}
If the problem rises due to difficulties in implementation, the team can quickly pitch in
and address the issue.

\subsubsection*{Risk 4: Specification Breakdown}
\\
This problem can occur in many different situations like specifications developed incorrectly
or some members of the team did not understand the specifications.
\\
\\{\bf Likelihood of occurring:} medium
\\{\bf Impact if it occurs:} medium
\\{\bf Evidence:}
Each member of the team has a specific module that they were assigned to design. However, each
module was designed base on the specifications of the other modules. If someone fails to
understand the flow of the system from the specifications, then progress will be slowed down. 
\\{\bf Steps to reduce likelihood/impact:}

1. Document the specifications

2. Review specifications during meetings

3. Corresponding members should communicate specifications between related modules
\\{\bf Plan for detecting the problem:}
The project manager should fully understand how the individual pieces of the system fit together
and make sure that everyone on the team understand their specifications.
\\{\bf Mitigation plan should it occur:}
If the problem occurs due to bad development, the project manager should step in and make critical
decisions. If it's the case where people have a hard time understanding the specifications, any
other member of the team should be able to help out.

\subsubsection*{Risk 5: Member Loss}
\\
A member of the team has to leave for some reason. This results in a drop in human resources.
\\
\\{\bf Likelihood of occurring:} low
\\{\bf Impact if it occurs:} high
\\{\bf Evidence:}
The likelihood of this occurring is virtually zero since everyone understands that they are
responsible for the well being of the team. Everyone is dedicated to see the completion of
the project. However, our team will suffer greatly if for some unpredictable reason that we
lose a member of our team. This is because our team consists of only six people.
\\{\bf Steps to reduce likelihood/impact:}

1. Have everyone on the team be prepared to take on extra load when necessary.

2. Plan ahead for a necessary organization of the team that would address this issue.

3. The person leaving should alert the team as soon as possible
\\{\bf Plan for detecting the problem:}
Everyone must be responsible for their own personal issues and alert the team if their
own problems will harm the effectiveness of the team.
\\{\bf Mitigation plan should it occur:}
Reorganize the team to address the situation. Follow the plan that was prepared for this exact
situation.

\subsubsection*{Risk 6: Customer Wants New Features}
\\
Deep in the stages of development, the customer decided to request unexpected features
\\
\\{\bf Likelihood of occurring:} high
\\{\bf Impact if it occurs:} high
\\{\bf Evidence:}
The likelihood of this occurring is very high because the customer never fully understand
what kind of features are desired during the beginning stages of development. The impact of
this can range from minor tweaks of the software to unreasonable design changes. In the case
where the newly desired features are impossible to implement in the given time, they will
most likely be rejected. The customers may feel disappointed if their requests are rejected
\\{\bf Steps to reduce likelihood/impact:}

1. Frequent meetings with the customer to discuss the possibilities of new features

2. Provide regular releases of the software so the customer understands what kind of
features are feasible
\\{\bf Plan for detecting the problem:}
Check if the customer is satisfied with the development progress. If customer is unhappy,
then it is likely that they will demand changes.
\\{\bf Mitigation plan should it occur:}
Discuss with customer on whether new features are possible base on resource availability.
Explain to the customer if resource demands are required to implement new features.

\subsubsection*{Risk 7: Testing Issues}
\\
Test plans were made and documented well but actual testing resulted in disaster
\\
\\{\bf Likelihood of occurring:} mid
\\{\bf Impact if it occurs:} mid
\\{\bf Evidence:}
Even though the amount of testing and the associated plans were made early, there are
still a fair amount of likely risks associated due to designing a new system. The
tests might turn out to be difficult to write. Bug tracking will be an important issue
if testing is to become an issue.
\\{\bf Steps to reduce likelihood/impact:}

1. Test early and frequently

2. Fix and document any problems that occur from testing.
\\{\bf Plan for detecting the problem:}
Set up an automated test. By having tests run regularly and automatically, the process
of catching errors will itself be less error-prone.
\\{\bf Mitigation plan should it occur:}
Address the issues and restructure the test plans if necessary.

\subsubsection*{Changes to Risks since the SRS}
The biggest concern in the SRS was around the fact that we might be working with a system
that is beyond our control, specifically the routing algorithm from the PhD student. Turns
out that we will not be working with any external system thus this issue is no longer a risk.

The risks related with architecture design is generally the same as in the SRS, but now they
are more obvious and their likelihood/impact can be estimated base on the implementation
and specification details that we have discussed since the SRS.